API change check

API changes are not detected in this pull request.

We used this feature. Our whole metrics is based on namespaces. Can we get more info behind this change? The link in the description is private. Our client was really upset. We get that exporter is in beta, but this is kind of a breaking change.

@macieyng

Apologies about the poor experience with your client. We do monthly releases of the exporter and the distro packages. You can find the latest release notes for the exporter here. You can check this page in the future for any breaking changes. We mistakenly placed the namespace change under "bug fixes" and not "breaking changes" this time. As for this specific feature, by default, metric namespace should not be mapped from instrumentation name. However, we are currently working on an opt-in method to bring this feature back if needed, which will be available next release. I will be making a quick release (sometime by the end of this week) due to the urgency for your client. Thanks for your understanding.

@macieyng

Just a followup on the above. May I ask if depending on the namespace is absolutely necessary? What is the reason you need to use namespace (and not let say, metric name). Are you in need of identifying which instrumentation generated that specific metric (like opentelemetry.instrumentation.requests for example)?

I guess it's not necessary. For us namespace value was a service name. We implemented in this style some amount of our metrics and we have Azure Dashboards depending on it, that business is constantly looking at. So when we did update, prod dashboard went blank for one service. On our end we would have to make changes to dashboards and reimplement metric names. Like no we have namespace: order_service and metric name orders_count and we would probably have to change that to order_service.orders_count. Not a big deal, but it's just how we used it.

We would appreciate a solution that we not require as to do a lot of development, if that's possible. Currently we froze monitor exporter at 1.0.0b17.

@macieyng

By design, namespace was never supposed to be used so it was an erroroneous feature on our part. Metric groupings should be handled by metric attributes ("apply splitting" feature in metrics explorer). If you don't see an attribute that you can use that you can use to logically split the metrics the way you desire, we can expose that for you, but namespaces should not be used anymore.

Okay. We'll better focus on development on our end then.

@lzchen - as always - thank you for your support!

@lzchen If namespace was never supposed to be used, should we remove it from the metrics dashboard? currently when you create a dashboard, you had to choose a namespace first. That's why customer might think they still need this.

If we decide not to bring it back, seems we also need to update the doc which still mentions that the metrics namespace can be customized.

@wxpjimmy

Can you paste a link to the doc that says this.

here's the link: https://learn.microsoft.com/en-us/azure/azure-monitor/app/opentelemetry-add-modify?tabs=python%2Cpython-2%2Caspnetcore-3%2Caspnetcore-4%2Caspnetcore-5%2Caspnetcore-6%2Caspnetcore-8%2Caspnetcore-9%2Caspnetcore-10%2Caspnetcore-11%2Caspnetcore-12%2Caspnetcore-13%2Caspnetcore-14%2Caspnetcore-15#included-instrumentation-libraries

@wxpjimmy

Thanks for bringing this to our attention. We will work on correcting the docs.

@macieyng @wxpjimmy

We have decided to expose this feature via an opt-in. Here is the pr. This will be available in the next release.